Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/91nov/devdisc-minutes-91nov.txt

Text File | 1993-02-17 | 12KB | 255 lines

CURRENT_MEETING_REPORT_


Reported by Fred Baker/ACC

SNMP Device Discovery BOF Minutes

Prior to meeting at the IETF, there was an extended discussion on the
SNMP and [e-mail] mailing lists.  It is summarized as
follows, as it represents a significant context to the BOF held at the
IETF meeting.

Essentially, we have two problems and at least three solutions on the
table.  The purpose of the BOF is exploratory - there exists a subset of
individuals who feel that there is no viable problem to solve, and if
there is it should not be solved; there are others who support various
viewpoints.  We need to get all the laundry on the table and come up
with a problem statement before we can either proceed or decide to not
proceed.

The problems are:


   o Within a single administrative domain, it should be possible for
     Network Management Systems to locate all of the systems appropriate
     for them to manage (e.g., with SNMP) without preconfiguration.
     This is believed to be helpful to Network Managers in that they now
     have positive assurance that they do in fact know all of the key
     devices in their networks.  This viewpoint has been presented by a
     couple of vendors, and was in fact the start of the discussion.

   o Within a single administrative domain, it is possible and probable
     that devices are added to the network without the knowledge of the
     network manager.  Several Network Managers have indicated a desire
     to know literally all of the devices on their networks, and their
     network layer attributes.
     The potential solutions may be classified as ``first person'',
     ``second person'', and ``third person'' solutions, and there are a
     couple of variations on each of those:
     First Person:
     Examples of current deployment:
     Wide area:  RWHO...  Immediate Neighbor:  OSPF, ES-IS, IS-IS,
     DECNET, RIP, DECNET, DEC MOP, DEC LAT...
     Each SNMP-manageable device on the network periodically emits a
     trap which announces its presence to interested parties.  The trap
     is sent to a multicast which is received by interested parties on
     the extended LAN. Its contents include Object Identifiers of MIB
     Groups supported by the device, system.sysObjectID, and the
     Read-only community string/party to be used with this agent.  If we
     presume that the probability that a multicast will reach all of its
     intended recipients > some value, then the probability that all of
     the network managers know about all of the devices they should
     manage within some amount of time is a function of the emission
     rate and the time limit.

                                   1





A second version of this might use IP Multicasting to propagate
information throughout the administrative domain.
Concerns:
First approach:  Impact of SNMP Security Architecture not yet
analyzed.  Does not propagate information beyond router.
Second approach:  scaling, definition of administrative boundaries,
some details in SNMP. Impact of SNMP Security Architecture not yet
analyzed.
Doesn't solve second problem.
second person:  Examples of current deployment:  ARP, 802.5 RIF
Discovery, DEC RBMS
Each interested party does something to elicit a response from the
systems it is concerned about.  This might include sweeping MIBs
and then pinging new folks discovered in ARP caches, etc.  Someone
has suggested letter bombs - broadcast a GET system.sysDescr, and
collect the responses.  In the latter class of solution, there
would need to be either some random ``host delay'' to avoid
flooding the network, or an ``exclusion group'' to advise
responders to NOT respond.
Concerns:  scaling, traffic level, both burst and sustained,
definition of administrative boundaries.
Sweeps may solve second problem, or at least part of it, but this
is not assured.  broadcast ``pings'' only solve it for the
architectures whose ``ping'' is used, and not all architectures
define a ``ping''.
third person:  Examples of current deployment:  RMON MIB
A subset of the systems in the network actively notify the
interested NMSs of new systems that they detect.  ``Detection'' is
somewhat imprecise - one proposal defines detection to be a
protocol specific neighboring relationship; another defines it as
the use of a LAN source address.  In the latter, the RMON MIB is
proposed as a solution.
Concerns:
With the RMON MIB, no network layer information is captured.  If
the network manager is not on the local wire with the system found,
it has no information other than the MAC Address and the location
of the monitor with which to do anything further and no protocol
with which to get it.
With the RMON MIB, only LAN systems are detected, and then only on
LANs that have objects defined in RMON. As it stands today, RMON is
fairly obviously targeted at Ethernet.  For use on Token Ring or
FDDI, there is additional work defined by the RMON WG. Multipoint
networks such as SMDS and Frame Relay are not addressed; this may
or may not be an issue - can we assume that contracts exist in the
presence of these technologies?  Are private networks a concern?
With the protocol specific detection, a router or bridge could
advertise the MAC and network layer information to the NMS; the
fact that a TRAP is unreliable means that the NMS might nonetheless
fail to learn the information.  Use of a SET has been suggested,
but some feel that specifying an application residing in the router
or bridge is distasteful.  Each NMS could also poll the subset of
systems (monitors, routers, etc, a limited subset of the network)
for new information.
The BOF was started with a presentation by Anil Rijsinghani of

                              2





Digital, whose question on the SNMP Mailing List is what actually
started the whole debate.  His fundamental concern, echoed by some
other vendors, was that there is today no single, reliable, way to
find all of the SNMP Manageable devices in an administrative
domain.  Corollary to that, there is no way to determine what MIBs
any given station supports.  Even a MIB walk may not return that
information if a MIB is primarily composed of tables and the
service is not currently configured or active.  Mechanisms that are
available depend on assumptions that may not hold, such as the use
of the ``public'' community in SNMP or that SNMP capable systems
periodically send SNMP messages.  Other drawbacks of existing
mechanisms may include:  they are complex, generate excessive
traffic, and require every NMS to perform its own discovery.
Requirements of a solution to this problem include:  it should be
reliable (discover every SNMP device), be simple, use small amount
of network bandwidth, require a small amount of agent effort,
should work regardless of powerup sequence, impose a low load on
others and convey useful standardized information.
The remainder of the BOF was given over to determining what problem
the assembled company wanted to solve; this is a non-trivial
problem in its own right.  The discussion was as wide-ranging, and
a number of quite divergent opinions were presented.  It was
generally felt that the problems of finding all SNMP capable
systems, finding all SNMP/UDP/IP capable systems, and finding all
systems that use the Internet were quite distinct and call for
different solutions, and that finding all equipment attached to the
Internet is not a solvable problem.
After much discussion, it was concluded that the fundamental
problem seeking solution borrowed components of each of these
problems.  Network Managers do in fact need to know what equipment
is attached to their networks, and are helped by products which
will perform this function.  Products that do this utilize the RMON
MIB, proprietary MIBs and algorithms, and scan such tables as the
ARP cache and Routing cache.  However, the problem of device
discovery does not include a number of other functions (such as
drawing a picture or matrix of Internet connectivity).  These are
``next step'' processes which follow the discovery of the systems
in the network.
Given this much problem definition, the conclusion was reached that
the RMON MIB could be extended to solve much of the discovery
process.  The reasons that it is inadequate now are:
it is limited to finding systems attached to LANs, and
it does not capture the protocol type or network layer protocol
addresses that a device is using.
As a result, the information captured about a system found by RMON,
as it stands, cannot be used to perform the next step, that of
pinging the device, especially if the device is separated from the
NMS by a router.  Therefore, the ultimate solution reached was to
recommend that the RMON MIB be extended with a table containing, at
minimum, the following information:
deviceTable deviceEntry [deviceMacAddress, deviceProtocol]
deviceMacAddress OCTET STRING deviceProtocol OCTET STRING or OBJECT
IDENTIFIER deviceProtocolAddress OCTET STRING
There may not be a protocol address for all protocols layered onto

                              3





the Data Link Layer, so the NMS must expect that
deviceProtocolAddress may have a length of zero octets.
A prototype MIB will be forwarded to Mike Ehrlinger of MTI for
consideration by the RMON WG.
Attendees
Miriam Amos Nihart       [e-mail]
Robert Austein           [e-mail]
Fred Baker               [e-mail]
Steve Bostock            [e-mail]
David Bridgham           [e-mail]
Theodore Brunner         [e-mail]
Jeffrey Buffum           [e-mail]
Lida Carrier             [e-mail]
Jeffrey Case             [e-mail]
Richard Cherry           [e-mail]
James Codespote          [e-mail]
Dave Cullerot            [e-mail]
James Davin              [e-mail]
Jeff Erwin
Bill Fardy               [e-mail]
Shawn Gallagher          [e-mail]
William Jackson          [e-mail]
Ron Jacoby               [e-mail]
Satish Joshi             [e-mail]
Scott Kaplan
Frank Kastenholz         [e-mail]
David Kaufman
Manu Kaycee              [e-mail]
Mark Kepke               [e-mail]
Yoav Kluger              [e-mail]
Stev Knowles             [e-mail]
Deidre Kostick           [e-mail]
Ron Lau
Keith McCloghrie         [e-mail]
Evan McGinnis            [e-mail]
David Minnich            [e-mail]
Michael Newell           [e-mail]
David Perkins            [e-mail]
Radia Perlman            [e-mail]
Robert Purvy             [e-mail]
Anil Rijsinghani         [e-mail]
Michael Ritter           [e-mail]
Jonathan Saperia         [e-mail]
Mark Schaefer            [e-mail]
John Seligson            [e-mail]
Timon Sloane             peernet![e-mail]
Ravi Srinivasan          [e-mail]
Bob Stewart              [e-mail]
Bruce Taber              [e-mail]
Iris Tal                 [e-mail]
Mark Therieau            [e-mail]
Dean Throop              [e-mail]
John Veizades            [e-mail]
Sudhanshu Verma          [e-mail]

                              4





Lee Wade                 [e-mail]
Steven Waldbusser        [e-mail]
Jeremy Wilson
Junekang Yang            natadm![e-mail]
John Ziegler             [e-mail]



                              5